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(57) Abstract 



System and method for fully transparent IP mobility services for clients in a dynamic LAN Ethernet environment. The functionality 
within a proxy server, a combination of network address translation, proxy address resolution protocol, and proxy domain name service, 
allow the proxy server to support and provide full IP client functionality to any IP-enabted network device in any proxy server enabled 
LAN. The proxy server may be added to an existing Ethernet (or Ethernet-emulated) LAN. Once configured with the necessary subnet 
range, DNS, and IP pools, the proxy server provides support for any mobile device that enters the LAN. 
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PROXY SERVER FOR TCP/IP NETWORK ADDRESS PORTABILITY 

Background of the Invention 
The present invention relates generally to address portability and, more particularly, 
to a method and apparatus for address portability to provide fully transparent internet 
protocol (IP) mobility services to IP-enabled network devices in any Ethernet local area 
network (LAN). 

The transmission control protocol/internet protocol (TCP/IP protocol), a suite of 
communications protocols used by host computers to exchange information between 
application processes over LANs or wide area networks (WANs), was designed when 
laptops and other mobile IP devices were essentially nonexistent. As a result, there was 
no issue with mobility, since each IP network device was typically a workstation, 
minicomputer, or the like. The movement of devices from place to place in such a static 
environment was expected to be a very rare occurrence, and one that could be adequately 
handled by manual intervention. This assumption, in conjunction with various resource 
constraints, influenced the development of the IP protocol such that each LAN only 
operated with a limited range (a subnet) of IP addresses. Any device with an IP address 
outside of that range was simply ignored by the LAN's router, rendering it unable to 
communicate with any device within that network. 

Over the last several years, the IP protocol has become the primary data 
communications protocol on virtually every computer in the world. This includes a 
substantial number of laptops and other portable computer devices. As the prevalence of 
laptops increases, IP mobility issues have substantially increased. For example, it is now 
common for customers, vendors, and even business associates that have laptops or other 
mobile IP devices to attempt to hook into a "foreign" LAN and attempt to use its facilities. 
Typically, this results in significant frustration since the amount and complexity of 
reconfiguration to permit the connection is not insubstantial. 

One attempted solution to this problem, dynamic host configuration protocol 
(DHCP), evolved over the last couple of years. Under DHCP, a computer configured to 
use that protocol may retrieve local IP configuration data automatically when the mobile 
IP device is connected to the network. While this is a reasonable solution to mobility 
problems, its scope is somewhat limited. For example, the mobile network device must 
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be configured to use DHCP, and the LAN must have a DHCP server enabled. Moreover, 
the duration of DHCP "timeouts" within the mobile network device must be short enough 
to allow the device to request a new address at the new location. As a result of at least 
these limitations, DHCP has not sufficiently solved the problem. In some cases, DHCP 
5 has proven unacceptable to the network clients who may not have DHCP pre-configured 
or to network administrators who wish to have more knowledge of and control over the 
mobile IP devices that enter and leave the network. 

It is, therefore, desirable to provide fully transparent IP mobility services for clients 
in a dynamic network environment. 

!0 Summary of the Invention 

Systems and methods consistent with the present invention satisfy this and other 
needs by supporting and providing full IP client functionality to any IP-enabled network 
device in any mobility-enabled LAN. The present invention provides fxill functionality 
regardless of both the IP address of the mobile device and subnet restrictions of the LAN. 

15 A method for use with a proxy server consistent with the present invention 

establishes communications between a device in a first network and a destination device 
having an arbitrary address on a second network outside of the first network. The method 
includes the step of generating an address resolution protocol packet to identify the 
arbitrary address for the destination device. The proxy server receives the address 

20 resolution protocol packet and generates an address resolution protocol response packet 
including the arbitrary address of the destination device. The method also includes the step 
of transmitting the address resolution protocol response packet from the proxy server to the 
device in the first network. 

Another method consistent with the present invention is for use with a proxy server 

25 and establishes communications between a random device and a destination device having 
an arbitrary address on a network. The method includes the steps of generating an address 
resolution protocol packet to identify the arbitrary address for the destination device and 
receiving, by the proxy server, the address resolution protocol packet. The method also 
includes the steps of generating an address resolution protocol response packet including 

30 the arbitrary address of the destination device and transmitting the address resolution 
protocol response packet from the proxy server to the random device. 
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Yet another method consistent with the present invention is for use with a proxy 
server which is in communication with a mobile device and remote name server. The 
method permits obtaining an internet protocol address from the remote name server for the 
mobile device and includes the steps of generating a query packet including a request for 
5 an address associated with a domain name and receiving the query packet from the mobile 
device in the proxy server. The method also includes the steps of forwarding the query 
packet to the remote name server and generating a response packet including the requested 
address. The method also includes transmitting the response packet to the proxy server and 
transmitting the response packet to the mobile device. 

1 0 Another method consistent with the present invention is for use with a proxy server 

and provides for communications between a random device and a destination device in a 
network. The method includes the steps of performing a proxy address resolution protocol 
to initiate communications between the random device and the destination device, 
performing a proxy domain name service to identify a destination address in the second 

1 5 network associated with a domain name, and performing a network address translation of 
an arbitrary random address associated with traffic from the random device to an 
appropriate address for routing the traffic to the destination device in the network. Use of 
this combination allows a system to support and provide full client functionality to mobile 
network devices. 

20 Systems are also provided for carrying out these and other methods consistent with 

the present invention. 

Several advantages accrue to methods and systems consistent with the present 
invention. For example, these systems and methods provide a secure and complete 
mobility solution, including the various cases where prior art solutions were inadequate. 

25 Such systems and methods are completely transparent to the end-user, who may or many 
not use DHCP, but will still be able to communicate with a LAN or even with a WAN. 
They are also more "administrator-friendly", especially when the acceptance protocol 
involves e-mail notification to the network administrator that a new device has joined the 
network. Security is enhanced by reducing the network's exposure to foreign snooping. 

30 The above and additional features and advantages of the present invention will be 

readily appreciated by one of ordinary skill in the art from the following detailed 
description. 
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Brief Description of the Drawing s 
Figure 1 is a diagram of a random Ethernet LAN environment consistent with the 
present invention; 

Figure 2 is a high level system diagram of a proxy server consistent with the present 
5 invention; 

Figures 3 and 4 illustrate network address translation associated with the routing 
of traffic from a random LAN to a legal LAN consistent with the present invention; 

Figures 5 and 6 illustrate network address translation associated with the routing 
of traffic from a legal LAN to a random LAN consistent with the present invention; 
1 0 Figures 7 and 8 illustrate generation of a proxy address resolution protocol (ARP) 

packet and generation of a proxy ARP response packet consistent with the present 
invention; 

Figures 9-12 are flowcharts depicting steps for proxy ARP consistent with the 
present invention; 

15 Figures 13 and 14 illustrate generation of a proxy domain name service (DNS) 

query packet and generation of a proxy DNS response packet consistent with the present 
invention; 

Figures 1 5 and 1 6 are flowcharts depicting steps for proxy DNS consistent with the 
present invention; 

20 Figure 1 7 illustrates an alternative proxy server implementation consistent with the 

present invention; 

Figure 18 illustrates normal traffic flow in the alternative proxy server 
implementation of Figure 16; 

Figures 19-22 illustrate network address translation for use with the alternative 
25 proxy server implementation consistent with the present invention; and 

Figures 23-24 illustrate proxy ARP for use with the alternative proxy server 
implementation consistent with the present invention. 

Detailed Description of the Preferred Embodiments 
Reference will now be made in detail to embodiments consistent with this invention 
30 that are illustrated in the accompanying drawings. The same reference numbers in 
different drawings generally refer to the same or like parts. 
Two- Armed Proxy Server 
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Figure 1 shows a "random" LAN 10. For purposes of this discussion, "random" 
simply means there are a random number of mobile IP network devices, and those devices 
each use a random IP address. One example of a "random" LAN would an IP Ethernet 
network in a hotel. LAN 10 includes a plurality of interconnected mobile IP network 
devices, including laptops 12, 14, and 16, having IP addresses scattered across the range 
of known addresses. As shown, the plurality of network devices communicate through a 
hub 1 8 and a proxy server 20 with network router 22. The links used to interconnect the 
various network elements shown may, for example, be Ethernet links. In the LAN 10, 
proxy server 20 may be referred to as a "two-armed" (TA) proxy server since it possesses 
two network interfaces, e.g., two Ethernet links. 

Normally, this type of network would be extremely difficult to manage, since a 
standard router expects all IP addresses that it serves to fall within a limited range. 
Consistent with the present invention, however, traffic from each of these devices may be 
modified so that the information presented to the network router is acceptable. The 
modification may be accomplished by proxy server 20 using a combination of network 
address translation (NAT), a proxy address resolution protocol (ARP) service, and a proxy 
domain name system (DNS) service, as discussed below. NAT is a well-known process 
by which traffic received by and transmitted from a particular device with an arbitrary IP 
address is modified to present the correct IP address to a network router. NAT service may 
be specifically configured to translate particular IP addresses. A proxy mobility server 
consistent with the present invention may translate random IP addresses dynamically. 

Figure 2 illustrates a high level diagram of proxy server 20. As shown, proxy 
server 20 includes a processor in communication with a hard drive, a system memory, and 
a user memory. The system and user memories may include read-only and/or random 
access types of memories. These memories are useful for storing packet contents, which 
may includes addresses and the like, as well as data content and packet length, to name a 
few. Proxy server 20 also includes interfaces, which may take the form of cards, through 
which proxy server communicates with networks. In the example shown, proxy server 20 
is interfaced with a legal/public network and a random network through Ethernet interface 
0 and Ethernet interface 1, respectively. 

Figures 3 and 4 depict the routing of information, such as an IP packet 26, from a 
device within a random LAN 28 to a device within a "legal" LAN 30. For purposes of this 
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discussion, a "legal" LAN is simply a public LAN, z. e. , one with a legal set of IP addresses. 
In Figure 3 , packet 26 from the device, which has an IP address of 47.3 1 . 1 28 . 1 95, is routed 
from random LAN 28 to proxy server 20. As shown, proxy server 20 is a server for a 
subnet (here denoted 137.11 8. 199.X) which, as is known, is a set of machines that are 
5 physically connected together in an Ethernet LAN, e.g., the legal LAN 30 in Figure 3. 
Proxy server 20 performs a network address translation and, as shown in Figure 4, the 
translated packet 32 is transmitted to the legal LAN. The translation may be performed 
using known techniques, such as those specified in Internet Engineering Task Force 
Request for Comments (IETF RFC) 1631. A packet following the opposite path, i.e., 
10 packet 34 routed from a device within legal LAN 30 to a device within random LAN 28, 
would also undergo network address translation (to translated packet 36) in proxy server 
20 (see Figures 5 and 6). 
Proxy ARP 

In addition to NAT, proxy server 20 may employ a proxy address resolution 
15 protocol (ARP) service to provide mobile functionality consistent with the present 
invention. ARP is a known protocol which may be used by a network device to discover 
what other devices are connected to the local network. Proxy ARP service allows TA 
proxy server 20 to "spoof mobile network IP devices having random IP addresses into 
thinking that server 20 is the device with which those mobile IP devices wish to 
20 communicate. This is necessary when the mobile IP device first boots and attempts to 
determine its gateway. As is known, existing proxy ARP implementations are limited in 
their use since only traffic from certain select specific addresses can be handled. Proxy 
ARP consistent with the present invention is not so limited and may be used to identify any 
arbitrary address. 

25 Figure 7 illustrates an ARP packet 38 being transmitted by a mobile device in 

random LAN 28 to proxy server 20. As shown, ARP packet 38 includes the address of the 
sending device, as well as a query from the device regarding the whereabouts of its 
gateway, which has the address of the gateway sought. The gateway, which may be a 
network router, connects the smaller LAN (e.g.., a random LAN) to a larger WAN (e.g., 

30 a public LAN, such as the "legal" LAN 30 of Figure 7) and passes traffic from the LAN 
to the WAN. When a mobile device in the random LAN wishes to send traffic to a device 
having an arbitrary address in a second network (e.g., the WAN) outside of the LAN, the 
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sending device needs to know to which gateway device the traffic should be sent. While 
normally the gateway is on the same network as the mobile device that is searching for it 
(using the ARP), this is not possible in a random LAN. Accordingly, the proxy server 
pretends that it is the gateway, and the mobile device will use it to reach the WAN. In 
5 response to receiving ARP packet 38, proxy server 20 generates an ARP response packet 
40 destined for the sending device in random LAN 28. As shown in Figure 8, response 
packet 40 includes the sending device's IP source address as the destination address and 
informs the sending device that proxy server 20 is the device's gateway. 

Figure 9 depicts steps for proxy ARP consistent with the present invention. During 

10 initialization (step 80), IP addresses and network masks are determined, as shown in 
greater detail in Figure 10. First, a raw socket is created to examine ARP packets (step 
100). This socket is, a communications programming interface created between proxy 
server 20 and the random and public LANs. In the Redhat Linux operating system, only 
one such socket is needed, whereas other operating systems, such as Sun Microsystem's 

1 5 Solaris operating system, must create one socket per Ethernet interface. Next, IP network 
masks for both the public LAN interface and the random LAN interface are identified 
(steps 102, 104). As is known, these interfaces may be cards in proxy server 20. This 
information, used by the proxy server in combination with other information to determine 
what set of devices are part of the networks and, therefore, whether it can send packets 

20 directly to any mobile device or whether the packets must be sent through a router, is 
typically maintained in a stable storage device, such as hard disk, flash memory, and the 
like, in proxy server 20. Similarly, IP addresses of the public and random LAN interfaces 
are identified (steps 106, 108), as is the medium access control (MAC) address of the 
random interface (step 1 10). Like the IP network masks, these addresses are typically 

25 stored or built into proxy server 20. 

With continuing reference to Figure 9, when a new ARP packet from a random IP 
device, such as ARP packet 38 of Figure 7, arrives at the random network interface from 
a mobile IP device in the random LAN (step 82), proxy server 20 retrieves the packet 
contents from the operating system (step 84). The packet, as is known, has a header and 

30 data, which includes inter alia the packet source address (i.e. , the address of the mobile 
device that sent the ARP packet) and the packet destination address (/. e. , the address of that 
device's gateway). The server then applies the ARP data format to the IP packet (step 86). 
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The ARP data format is defined in IETF Standard 37, and the application of the format to 
the data may be done using the standard method of casting. 

Next, the proxy server performs a proxy ARP network determination to determine 
the network to which the.IP packet is destined for (step 88). Figure 1 1 shows a flowchart 
5 detailing steps for this determination consistent with the present invention. A public 
network ID (PubNetID) is determined first (step 120). In one embodiment, the public 
network ID is derived from the public IP interface address and the IP network mask of the 
public LAN, e.g. , logically "anding" the address with the mask. The proxy server uses the 
PubNetID to discover what network it is part of, i.e., what IP devices are local and which 

10 are not local. Devices that not local are reached through a router. Next, the proxy server 
determines if the IP destination address of the incoming packet is for a "local" network, 
i.e., the public LAN. In one embodiment, a network ID associated with the incoming 
packet (NewNetID) is determined (step 122) based on the destination IP address sub- 
component of the. ARP data structure associated with the ARP packet and the IP network 

1 5 mask of the public LAN interface, e.g. , logically "anding" the destination address with the 
public IP network mask. If PubNetID is equal to NewNetID (step 124), the incoming 
packet is destined for a device that has an IP address on the public LAN but is physically 
part of or on the random LAN. The proxy server discards this incoming packet (step 126) 
because another device in the random LAN will receive the packet by Ethernet. The proxy 

20 server simply ignores the packet because it does not need to create a response packet; the 
intended device physically on the random LAN should respond. 

If the incoming packet is not destined for the public LAN, a random network ID 
(RandNetID) may be determined based on the random IP address and the IP network mask 
of the random LAN, e.g., logically "anding" the address with the mask (step 128). The 

25 proxy server uses RandNetID to discover what devices are local to the random LAN. 
Devices that not local are reached through a router. A network ID associated with the 
packet (NewNetID2) is also determined (step 130). This may be determined based on the 
destination IP address sub-component of the ARP data structure associated with the ARP 
packet and the IP network mask of the random LAN interface, e.g. , logically "anding" the 

30 destination address with the random IP network mask. The proxy server uses this 
information to determine if the IP destination address of the ARP packet is for a "local" 
network, i.e., the random LAN. RandNetID may then be compared to NewNetID2 (step 



WO 99/38303 PCT/US99/01 1 95 

-9- 

132). If RandNetld is equal to NewNetID2 5 the incoming packet is destined for a device 
that has an IP address on the random LAN and physically part of or on the random LAN. 
Again, the proxy server discards the incoming packet (step 134), since another device in 
the random LAN should respond and will receive the packet by Ethernet. 
5 If the incoming packet has not been discarded by the proxy server based on these 

comparisons, the packet is destined for a device outside of a local network, i.e., from a 
device in a random LAN, such as a hotel, to a device outside of that LAN and physically 
part of, for example, a public LAN. Consistent with the present invention, the proxy server 
prepares an ARP response packet (step 136) to the incoming packet to convince the 

10 sending device that the proxy server is the device's gateway. The response ARP packet 
format is defined in IETF Standard 37. 

Referring once again to Figure 9, once an ARP response packet has been created, 
a proxy ARP address exchange is performed (step 90), as shown in Figure 12. Consistent 
with the present invention, the IP source address component from the incoming packet is 

15 copied into the destination address component of the response packet (step 140). This 
directs the response packet to the appropriate mobile IP device. Similarly, the source MAC 
address component of the incoming packet is copied to the destination MAC address of the 
response packet (step 142). The destination address component of the incoming packet is 
copied into the source address component of the response packet (step 144). Address 

20 exchange consistent with the present invention also contemplates filling in the source 
MAC address component of the response packet with the MAC address of the random 
interface (step 1 46). By inserting the operation component of the response packet with the 
appropriate value in network-byte order (e.g., the value "2" for RedHat Linux 5.0), the 
packet is considered a response packet for purposes of the ARP protocol. 

25 Once the address exchange is completed, the response packet may be written to the 

random Ethernet interface using a standard system call (Figure 9, step 92). When the 
mobile IP device receives the response packet, it will believe proxy server 20 is its gateway 
from the random LAN to outside public LANs. Subsequent traffic destined for public 
LANs will be routed there by the proxy server. 

30 Proxy DNS 

Normally, a mobile network device communicates with a nearby network element 
commonly referred to as a DNS server. The DNS server functions to translate an IP name 
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input by a user, such as "undefined.etherloop.com," into a corresponding IP address, such 
as 137.1 1 8. 199.33. Thus, when a mobile IP device user inputs an IP name as an intended 
destination, the device communicates with the DNS server, which then performs a 
translation, e.g., a name lookup. However, with a random LAN, this is not possible. 
5 Figure 13 shows the transmission of a DNS packet 42 from a mobile IP device 

within random LAN 28 to proxy server 20. Consistent with the present invention, the 
proxy server pretends that it is the correct DNS server and handles the DNS translation 
activities. In general, DNS packet 42 includes the IP address of the sending mobile IP 
device, a destination address, i.e., the address of the DNS server, which is typically 

1 0 preconfigured in the device, and the IP name the device is seeking an IP address for. Proxy 
server 20 redirects the request to a local process, i.e., a process within the proxy server 
which, in turn, performs the required translation. After the translation is performed, proxy 
server 20 generates a DNS response packet 44 (see Figure 1 4) which includes the address 
of the sending network device as a destination address and the IP address corresponding 

15 to the IP name. 

Figure 1 5 depicts steps for proxy DNS consistent with the present invention. First, 
the proxy DNS server is initialized (step 150). As shown in Figure 16, during 
initialization, proxy server 20 creates an unreliable datagram protocol (UDP) datagram 
socket (step 170) using known methods. This socket is a communications interface 

20 between the local process (proxy DNS) and the operating system. Proxy server 20 also 
establishes a firewall rule such that any packet headed for any destination in any LAN or 
WAN (Le., any IP address) from any source in any LAN or WAN with a destination port 
of "53" is delivered to the proxy server 20 at the same port, i.e., port "53" of the server 
(step 172). Port "53" is the port for the DNS server of the host machine (a machine with 

25 an IP address). The socket can then be bound to port "53" using standard methods (step 
1 74), such that any DNS query with a destination of port "53" is routed to the local process 
(proxy DNS). The identity of a remote name server physically located outside the random 
LAN on the Internet is also identified by the proxy server using, for example, a 
configuration file or some other known method (step 1 76). After creating a UDP socket 

30 association between the proxy DNS server and the identified remote name server (step 
1 78), proxy server 20 enters a loop waiting for new connections, such as new DNS queries 
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from the random LAN or DNS responses from the remote name server, using standard 
methods (step 180). 

After proxy DNS initialization, a "random" client (i. e. , a device in the random LAN 
having an IP address, such as 1.1.1.1) makes a DNS query to the identified remote name 
5 server (e.g., having an IP address, such as 2.2.2.2) at port "53" (step 152) using standard 
DNS protocol, e.g., IETF standard 13. Proxy server 20 receives the packet and, based on 
the port address used as the destination port (i.e., port "53"), redirects the packet to the 
proxy DNS server (the local process within the proxy server) (step 1 54) using, for example, 
firewall redirection code built into Linux Redhat 5.0. The proxy DNS server in turn 

1 0 receives the packet and determines the original destination address (L e. , 2.2.2.2) and port 
(i.e., port "53") of the intended destination, storing them in appropriate variables. In 
Redhat Linux 5.0, this may be accomplished using an appropriate system call to collect the 
packet data from the kernel. 

The proxy DNS server may then send the DNS query packet to the remote name 

1 5 server identified during initialization (step 158). The proxy DNS server creates a new UDP 
socket, a communications interface between it and the remote name server. Typically, the 
proxy DNS server uses a separate socket and port (such as port "2001," in this example) 
which may be arbitrarily assigned) for each mobile device IP address so as to be able to 
identify to which device in the random LAN the response should be sent. The remote 

20 name server then processes and responds to the DNS query from the proxy DNS server, 
as defined in IETF Standard 13 (step 160). A DNS response packet, which includes the 
requested address, is generated by the remote name server and sent to the proxy server 
using the port defined in step 158 (i.e., port "2001" in this example). Proxy server (such 
as proxy server 20) receives the DNS response from the remote name server on the 

25 specified port (i.e., port "2001") using, for example, standard Unix system calls and 
determines the IP address of the client (i.e., 1.1.1.1 in this example) using that port (step 
164). The DNS response is then sent to the client by the proxy server (step 166; see also 
Figure 14), which performs a source address and port modification. In one embodiment, 
the proxy server modifies the source address (the address of the proxy server, e.g., 3.3.3.3. 

30 in this example) and source port of .the response packet (the port of the link back to the 
client, which may be arbitrarily assigned) to the original destination address (i.e., 2.2.2.2. 
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in this example) and the original destination port (i.e., port "53" in this example) of the 
DNS query packet, respectively. 
One-Armed Proxy Server 

The TA proxy server described above is extremely well-suited for operation in any 
5 environment where a fully random assortment of users may attempt to connect to the LAN. 
As previously noted, one such environment is a hotel environment. Today, hotel guests 
frequently have mobile network devices, such as laptops, and wish to connect via Ethernet, 
EtherLoop, or the like, into the hotel's network and from there to the Internet to retrieve 
electronic mail and conduct other business. 

10 A TA proxy server, however, may not fit well into a LAN networking community 

since most end-user network devices will have a stable IP address, correctly configured and 
assigned for the LAN, unlike the hotel environment. Moreover, a TA proxy server 
increases latency (delay) on a network. For at least these reasons, there is a need for proxy 
routers that do not interfere with the normal operation of a LAN. These services will exist 

15 on a normally configured LAN and only begin operation only when a random interloper, 
i.e., an individual device, connects to the network. The device that supports this service 
will be lower in cost and will not create any performance problems for the standard 
network traffic. 

Figure 1 7 illustrates an alternative proxy server implementation consistent with the 
20 present invention that satisfies this need. In this implementation, LAN 200 includes a 
plurality of mobile IP network devices 202, 204, and 206 which communicate with a router 
2 1 0 through hub 2 12. The links used to interconnect the various network elements shown 
may, for example, be Ethernet links. Proxy server 214 communicates with the various 
network elements through a single link, e.g., a single Ethernet interface. As such, proxy 
25 server 214 may be referred to as one-armed proxy server. Generally, proxy server 214 
includes the same hardware as proxy server 20 (Figure 2). The same Ethernet interface 
receives data from LAN 200 and delivers translated data back to the LAN. In Figure 1 7, 
the majority of the devices on the network are on the same network as the router. These 
devices operate normally without any interference from proxy server 2 1 4, which is always 
30 listening to the traffic on this network. Device 208, an interloper with an address of 
47.3 1 . 1 28. 1 95 will not be able to directly communicate with the router, which ignores all 
traffic from an address that is not in its network domain (i.e., 137.1 18. 199. X). One of the 
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benefits of this implementation is that the standard network traffic is not interrupted by the 
proxy server, as shown in Figure 1 8. As with the TA proxy server of Figure 1 , one-armed 
proxy server 214 performs network address translation, proxy ARP, and proxy DNS 
services to provide similar fully transparent client functionality to any IP-enable network 
5 device. 

Network Address Translation 

Figure 1 9 depicts a network environment useful for discussing NAT performed by 
one-armed proxy server 64. Network 220, an Ethernet type of network ; includes a 
plurality of interconnected network elements including router 222, workstation 224, hub 
1 0 226, and proxy server 214. Interloper 228 is also connected to LAN 220, although it is a 
foreign IP-enabled network device relative to the network, i.e., it is not part of LAN 220. 

As shown in Figure 19, interloper 228 generates a packet 230 for a LAN/WAN 
other than the LAN 220. Packet 230 includes the IP address of the transmitting device, 
interloper 228, as well as an IP address of the destination device, which is not particularly 
1 5 shown. Due to the nature of Ethernet networks, every element on the LAN receives packet 
230 from hub 226. The IP protocols within workstation 224 and similar network elements 
recognize that the destination is not a local network device and consequently ignore the 
packet. Router 222 may or may not accept packet 230 depending on the source IP address. 
Even if the router accepts the packet and passes it on to the LAN/WAN, the packet will not 
20 return to the router (address 137.1 18.199.1) since the source address is 47.31.128.195. 

Proxy server 214, however, recognizes that it is capable of properly translating 
packet 230 into translated packet 232 having an acceptable format utilizing known address 
translation methods (see Figure 20). Since translated packet 232 has an associated IP 
address recognizable by router 222, the router believes packet 232 originated from within 
25 LAN 220 and not by a foreign mobile device, i.e., interloper 228. As shown, packet 232 
includes the same destination address as packet 230. Once router 222 receives this packet, 
it can send the packet on to the Internet as normal. 

After the remote device receives the translated packet, it may generate a response 
packet. If so, the response packet 234 must be translated by proxy server 2 1 4 so that it can 
30 be delivered to interloper 228 (see Figure 21). Router 222'knows that the .55 IP address 
is associated with a device on its network. In this case, the device happens to be proxy 
server 214, but the router is unaware of the presence of the server nor does it matter to the 
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router that the destination is the proxy server and not a "normal" network device such as 
a workstation. Instead, router 222 simply forwards response packet 234 to proxy server 
214, just like it would forward any other packet to other network devices. At about the 
same time the proxy server receives response packet 234, interloper 228 also receives the 
5 response packet from hub 226. However, since the interloper 228 knows that its IP address 
is 47.31.128.195, it throws the response packet away. Consistent with the present 
invention, proxy server 214 receives the response packet, performs a reverse network 
address translation, and sends a translated packet 236 back out on the LAN through hub 
226 (see Figure 22). Packet 236 is broadcast across the entire LAN, but since only one 
1 0 device on the network has IP address 47.3 1 . 1 28. 1 95 (interloper 228), only that device will 
not discard the packet. Proxy server is able to specifically target the interloper by using the 
interloper's medium access control (MAC) address as the destination. 
Proxy ARP 

Figures 23 and 24 show a network environment useful for discussing the proxy 
1 5 ARP capabilities of proxy server 214. Interloper 228 may generate an ARP packet 23 8 in 
order to discover the MAC Address of its gateway device, i.e., 47.31.128.1. Normally, 
since no device in LAN 220 has the appropriate MAC address, packet 238 would be 
ignored and interloper 228 would be unable to function. Consistent with the present 
invention, proxy server 2 1 4 will however recognize that packet 23 8 does not belong on the 
20 137.118.199.X network and will automatically generate a response (see Figure 24). 
Response packet 240 includes, as a destination address, the IP address of interloper 228, 
as well as a reply to the gateway query. Once interloper 228 receives packet 240, it 
considers the proxy server 214 to be its gateway device and will use the server for all 
further communications outside of the local LAN. The steps for proxy ARP performed by 
25 TA proxy server 20 discussed above are equally applicable to proxy server 214. 
Proxy DNS 

Proxy server 214 is also capable of performing proxy DNS. If, from the point of 
view of the interloper, the DNS server is usually on the same LAN as the interloper, the 
interloper will generate an ARP request for the DNS server. Consistent with the present 
30 invention, the proxy server 214 will respond to the ARP request with its own address. 
Future DNS queries will be delivered directly to proxy server 214, which can then answer 
them. Similarly, if, from the point of view of the interloper, the DNS server is outside of 
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the local LAN, i.e., on a WAN, the proxy server will automatically receive the DNS query, 
since it is the interloper's gateway. In this case, proxy serve 214 will see the DNS query 
packets arrive and will be able to response to them locally. The steps for proxy DNS 
performed by TA proxy server 20 discussed above are equally applicable to the proxy DNS 
5 service performed proxy server 214. 

In addition to the features described above, proxy servers consistent with the 
present invention support certain security functions to improve network administration. 
For example, each time an interloper connects to an proxy server-enabled network, the 
proxy server will be able to provide connectivity for that user. To improve the security of 

10 the network, the proxy server will deliver a message to a specified network administrator 
e-mail account to the alert the administrator to the presence of this new user. While this 
is not ironclad security, it is a reasonable first step in network security. 

Properly configured, proxy servers consistent with the present invention can 
provide interlopers with a secondary gateway. This has at least two benefits, including 

15 reduced congestion on the standard router and improved control over the interloper's 
internet access. Reduced congestion is a relatively straightforward concept, Le. 9 by using 
a different router than the standard network traffic, it reduces the possibility of excessive 
demand on router resources, that in turn might affect the performance of the standard 
network users. Further, by specifying a secondary gateway, the network administrator can 

20 funnel interlopers into a less open corporate environment, preventing those users from 
reaching sensitive material within the standard corporate network. This is one of the major 
benefits of the present invention ovfer the straight DHCP model, for two reasons. First, if 
the network is served by a proxy server, a stand-alone DHCP server is not needed. The 
standard network users will not need to use DHCP on a day-to-day basis. Given the first 

25 constraint, everyone who uses DHCP is, by implication, an interloper and can be treated 
with additional security restrictions. 

As for other protocols, one of ordinary skill will appreciate that proxy servers 
consistent with the present invention are only capable of supporting IP-based translation 
services. This is primarily because IP is both a LAN and WAN protocol. Other common 

30 LAN protocols, such as Apple Talk, or IPX are significantly limited in scope, and are not 
capable of the "long range" communications that make the proxy server translation services 
possible. However, it may be possible for "bridges" to be built to allow IPX-based 
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computers to communicate with their "home" networks. However, this must currently be 
resolved on a case-by-case basis. 

It will be appreciated by those skilled in this art that various modifications and 
variations can be made to the IP mobility service strategy consistent with the present 
5 invention described herein without departing from the spirit and scope of the invention. 
Other embodiments of the invention will be apparent to those skilled in this art from 
consideration of the specification and practice of the invention disclosed herein. It is 
intended that the specification and examples be considered exemplary only, with a true 
scope and spirit of the invention being indicated by the following claims. 
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We claim: 

1 . A method, for use with a proxy server, for establishing communications 
between a device in a first network and a destination device having an arbitrary address on 
a second network outside of the first network, the method comprising the steps of: 

5 generating an address resolution protocol packet to identify the arbitrary address 

for the destination device; 

receiving, by the proxy server, the address resolution protocol packet; 
generating an address resolution protocol response packet including the arbitrary 
address of the destination device; and 
1 0 transmitting the address resolution protocol response packet from the proxy server 

to the device in the first network. 

2. The method of claim 1 further comprising the step of: 

determining if the proxy server should respond to the address resolution protocol 

1 5 packet. 

3. The method of claim 2 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a device that 
20 has an address outside of the first network but that is part of the first network; and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address outside of the first network but that is part of the first network. 

4. The method of claim 3 wherein the step of determining if the proxy server 
25 should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a device that 
has an address on the first network and that is part of the first network; and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address on the first network and that is part of the first network. 

30 

5 . The method of claim 4 wherein the step of generating an address resolution 
protocol response packet includes the substep of: 
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generating a response packet if the address resolution protocol packet is destined 
for a device that is outside of the first network. 



6. The method of claim 5 further comprising the step of: 

performing an address exchange to direct the response packet to the appropriate 

device. 

7. The method of claim 6 wherein the step of performing an address exchange 
includes the substeps of: 

writing an internet protocol source address component of the address resolution 
protocol packet into a destination address component of the response packet; 

writing a source MAC address component of the address resolution protocol packet 
into a destination MAC address component of the response packet; and 

writing a MAC address associated with the first network into a source MAC 
address component of the response packet. 

8. A system for establishing communications between a device in a first 
network and a destination device having an arbitrary address on a second network outside 
of the first network, the system comprising: 

a proxy server in communication with the first network and the second network, 
the proxy server including: 

memory for receiving an address resolution protocol packet generated by 
the device in the first network; and 

a processor, in communication with the memory, for determining if the 
proxy server should respond to the address resolution protocol packet with an address 
resolution protocol response packet, the processor also for generating the response packet 
and transmitting the response packet to the device in the first network. 

9. A method, for use with a proxy server, for establishing communications 
between a random device and a destination device having an arbitrary address on a 
network, the method comprising the steps of: 
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generating an address resolution protocol packet to identify the arbitrary address 
for the destination device; 

receiving, by the proxy server, the address resolution protocol packet; 

generating an address resolution protocol response packet including the arbitrary 
5 address of the destination device; and 

transmitting the address resolution protocol response packet from the proxy server 
to the random device. 

1 0. The method of claim 9 further comprising the step of: 

10 determining if the proxy server should respond to the address resolution protocol 

packet. 

1 1 . The method of claim 1 0 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

15 determining if the address resolution protocol packet is destined for a device that 

has an address associated with the network but that is physically not part of the network; 
and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address associated with the network but that is physically not part of the network. 

20 

1 2. The method of claim 1 1 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a random 
device that is not part of the network; and 
25 discarding the address resolution protocol packet if it is destined for a random 

device that is not part of the network. 

1 3 . The method of claim 1 2 wherein the step of generating an address resolution 
protocol response packet includes the substep of: 

30 generating a response packet if the address resolution protocol packet is destined 

for a device that is part of the network. 
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14. The method of claim 13 further comprising the step of: 

performing an address exchange to direct the response packet to the appropriate 

device. 



5 15. The method of claim 14 wherein the step of performing an address 

exchange includes the substeps of: 

writing an internet protocol source address component of the address resolution 
protocol packet into a destination address component of the response packet; 

writing a source MAC address component of the address resolution protocol packet 
10 into a destination MAC address component of the response packet; and 

writing a MAC address associated with the random device into a source MAC 
address component of the response packet. 

16. A system for establishing communications between a random device and 
15 a destination device having an arbitrary address on a network, the system comprising: 

a proxy server in communication with the random device and the destination 
device, the proxy server including: 

memory for receiving an address resolution protocol packet generated by 
the random device; and 
20 a processor, in communication with the memory, for determining if the 

proxy server should respond to the address resolution protocol packet with an address 
resolution protocol response packet, the processor also for generating the response packet, 
and transmitting the response packet to the random device. 

25 1 7. A method, for use with a proxy server, for communicating with a mobile 

device and remote name server and for obtaining an internet protocol address from the 
remote name server for the mobile device, the method comprising the steps of: 

generating a query packet including a request for an address associated with a 
domain name; 

30 receiving the query packet from the mobile device in the proxy server; 

forwarding the query packet to the remote name server; 
generating a response packet including the requested address; 
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transmitting the response packet to the proxy server; and 
transmitting the response packet to the mobile device. 

18. The method of claim 17 wherein the query packet includes a destination 
5 port and wherein the step of forwarding the query packet to the remote name server 

includes the substeps of: 

directing the query packet to a proxy DNS server based on the destination port; 

determining, by the proxy DNS server, the address of the remote name server and 
the destination port; and 
1 0 identifying a port associated with the mobile device. 

19. The method of claim 18 wherein the step of transmitting the response 
packet to the proxy server includes the substeps of: 

receiving the response packet on the port associated with the mobile device; and 
1 5 determining, by the proxy server, the address of the mobile device based on the port 

associated with the mobile device. 

20. The method of claim 19 wherein the response packet includes a source 
address and a source port, and wherein the step of transmitting the response packet to the 

20 mobile device includes the substeps of: 

modifying the source address of the response packet to the address of the remote 
name server; and 

modifying the source port of the response packet to the destination port. 

25 21 . A system for obtaining an internet protocol address from a remote name 

server for a mobile device, the system comprising: 

a proxy server in communication with the mobile device and the remote name 
server, the proxy server including: 

memory for receiving an address query packet generated by the mobile 

30 device; and 
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a processor, in communication with the memory, for forwarding the query 
packet to the remote name server and for transmitting a response packet, generated by the 
remote name server and including the requested address, to the mobile device. 

5 22. A method, for use with a proxy server, for providing communications 

between a random device and a destination device in a network, the method comprising the 
steps of: 

performing a proxy address resolution protocol to initiate communications between 
the random device and the destination device; 
10 performing a proxy domain name service to identify a destination address in the 

second network associated with a domain name; and 

performing a network address translation of an arbitrary random address associated 
with traffic from the random device to an appropriate address for routing the traffic to the 
destination device in the network. 

15 

23. A system for providing communications between a random device and a 
device in a network, the system comprising: 
a proxy router including 
memory; and 
20 a processor programmed to 

(a) perform a proxy address resolution protocol to initiate 
communications between the random device and the device in the network; 

(b) perform a proxy domain name service to identify a destination 
address in the network based on a destination name; and 

25 (c) perform a network address translation of an arbitrary random 

address associated with traffic from the random device to an appropriate 
address for routing the traffic to the device in the network. . 
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PROXY SERVER FOR TCP/IP NETWORK ADDRESS PORTABILITY 

Background of the Invention 
The present invention relates generally to address portability and, more particularly, 
5 to a method and apparatus for address portability to provide fully transparent internet 
protocol (IP) mobility services to IP-enabled network devices in any Ethernet local area 
network (LAN). 

The transmission control protocol/internet protocol (TCP/IP protocol), a suite of 
communications protocols used by host computers to exchange information between 

10 application processes over LANs or wide area networks (WANs), was designed when 
laptops and other mobile IP devices were essentially nonexistent. As a result, there was 
no issue with mobility, since each IP network device was typically a workstation, 
minicomputer, or the like. The movement of devices from place to place in such a static 
environment was expected to be a very rare occurrence, and one that could be adequately 

15 handled by manual intervention. This assumption, in conjunction with various resource 
constraints, influenced the development of the IP protocol such that each LAN only 
operated with a limited range (a subnet) of IP addresses. Any device with an IP address 
outside of that range was simply ignored by the LAN's router, rendering it unable to 
communicate with any device within that network. 

20 Over the last several years, the IP protocol has become the primary data 

communications protocol on virtually every computer in the world. This includes a 
substantial number of laptops and other portable computer devices. As the prevalence of 
laptops increases, IP mobility issues have substantially increased. For example, it is now 
common for customers, vendors, and even business associates that have laptops or other 

25 mobile IP devices to attempt to hook into a "foreign" LAN and attempt to use its facilities. 
Typically, this results in significant frustration since the amount and complexity of 
reconfiguration to permit the connection is not insubstantial. 

One attempted solution to this problem, dynamic host configuration protocol 
(DHCP), evolved over the last couple of years. Under DHCP, a computer configured to 

30 use that protocol may retrieve local IP configuration data automatically when the mobile 
IP device is connected to the network. While this is a reasonable solution to mobility 
problems, its scope is somewhat limited. For example, the mobile network device must 
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be configured to use DHCP, and the LAN must have a DHCP server enabled. Moreover, 
the duration of DHCP "timeouts" within the mobile network device must be short enough 
to allow the device to request a new address at the new location. As a result of at least 
these limitations, DHCP has not sufficiently solved the problem. In some cases, DHCP 
5 has proven unacceptable to the network clients who may not have DHCP pre-configured 
or to network administrators who wish to have more knowledge of and control over the 
mobile IP devices that enter and leave the network. 

It is, therefore, desirable to provide fully transparent IP mobility services for clients 
in a dynamic network environment. 

10 Summary of the Invention 

Systems and methods consistent with the present invention satisfy this and other 
needs by supporting and providing full IP client functionality to any IP-enabled network 
device in any mobility-enabled LAN. The present invention provides full functionality 
regardless of both the IP address of the mobile device and subnet restrictions of the LAN. 

15 A method for use with a proxy server consistent with the present invention 

establishes communications between a device in a first network and a destination device 
having an arbitrary address on a second network outside of the first network. The method 
includes the step of generating an address resolution protocol packet to identify the 
arbitrary address for the destination device. The proxy server receives the address 

20 resolution protocol packet and generates an address resolution protocol response packet 
including the arbitrary address of the destination device. The method also includes the step 
of transmitting the address resolution protocol response packet from the proxy server to the 
device in the first network. 

Another method consistent with the present invention is for use with a proxy server 

25 and establishes communications between a random device and a destination device having 
an arbitrary address on a network. The method includes the steps of generating an address 
resolution protocol packet to identify the arbitrary address for the destination device and 
receiving, by the proxy server, the address resolution protocol packet. The method also 
includes the steps of generating an address resolution protocol response packet including 

30 the arbitrary address of the destination device and transmitting the address resolution 
protocol response packet from the proxy server to the random device. 
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Yet another method consistent with the present invention is for use with a proxy 
server which is in communication with a mobile device and remote name server. The 
method permits obtaining an internet protocol address from the remote name server for the 
mobile device and includes the steps of generating a query packet including a request for 
5 an address associated with a domain name and receiving the query packet from the mobile 
device in the proxy server. The method also includes the steps of forwarding the query 
packet to the remote name server and generating a response packet including the requested 
address. The method also includes transmitting the response packet to the proxy server and 
transmitting the response packet to the mobile device. 

1 0 Another method consistent with the present invention is for use with a proxy server 

and provides for communications between a random device and a destination device in a 
network. The method includes the steps of performing a proxy address resolution protocol 
to initiate communications between the random device and the destination device, 
performing a proxy domain name service to identify a destination address in the second 

1 5 network associated with a domain name, and performing a network address translation of 
an arbitrary random address associated with traffic from the random device to an 
appropriate address for routing the traffic to the destination device in the network. Use of 
this combination allows a system to support and provide full client functionality to mobile 
network devices. 

20 Systems are also provided for carrying out these and other methods consistent with 

the present invention. 

Several advantages accrue to methods and systems consistent with the present 
invention. For example, these systems and methods provide a secure and complete 
mobility solution, including the various cases where prior art solutions were inadequate. 

25 Such systems and methods are completely transparent to the end-user, who may or many 
not use DHCP, but will still be able to communicate with a LAN or even with a WAN. 
They are also more "administrator-friendly", especially when the acceptance protocol 
involves e-mail notification to the network administrator that a new device has joined the 
network. Security is enhanced by reducing the network's exposure to foreign snooping. 

30 The above and additional features and advantages of the present invention will be 

readily appreciated by one of ordinary skill in the art from the following detailed 
description. 
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Brief Description of the Drawings 
Figure 1 is a diagram of a random Ethernet LAN environment consistent with the 
present invention; 

Figure 2 is a high level system diagram of a proxy server consistent with the present 
5 invention; 

Figures 3 and 4 illustrate network address translation associated with the routing 
of traffic from a random LAN to a legal LAN consistent with the present invention; 

Figures 5 and 6 illustrate network address translation associated with the routing 
of traffic from a legal LAN to a random LAN consistent with the present invention; 
1 0 Figures 7 and 8 illustrate generation of a proxy address resolution protocol (ARP) 

packet and generation of a proxy ARP response packet consistent with the present 
invention; 

Figures 9-12 are flowcharts depicting steps for proxy ARP consistent with the 
present invention; 

15 Figures 13 and 14 illustrate generation of a proxy domain name service (DNS) 

query packet and generation of a proxy DNS response packet consistent with the present 
invention; 

Figures 1 5 and 1 6 are flowcharts depicting steps for proxy DNS consistent with the 
present invention; 

20 Figure 1 7 illustrates an alternative proxy server implementation consistent with the 

present invention; 

Figure 18 illustrates normal traffic flow in the alternative proxy server 
implementation of Figure 16; 

Figures 19-22 illustrate network address translation for use with the alternative 
25 proxy server implementation consistent with the present invention; and 

Figures 23-24 illustrate proxy ARP for use with the alternative proxy server 
implementation consistent with the present invention. 

Detailed Description of the Preferred Embodiments 
Reference will now be made in detail to embodiments consistent with this invention 
30 that are illustrated in the accompanying drawings. The same reference numbers in 
different drawings generally refer to the same or like parts. 
Two-Armed Proxy Server 
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Figure 1 shows a "random" LAN 10. For purposes of this discussion, "random" 
simply means there are a random number of mobile IP network devices, and those devices 
each use a random IP address. One example of a "random" LAN would an IP Ethernet 
network in a hotel. LAN 10 includes a plurality of interconnected mobile IP network 

5 devices, including laptops 12, 14, and 16, having IP addresses scattered across the range 
of known addresses. As shown, the plurality of network devices communicate through a 
hub 18 and a proxy server 20 with network router 22. The links used to interconnect the 
various network elements shown may, for example, be Ethernet links. In the LAN 10, 
proxy server 20 may be referred to as a "two-armed" (TA) proxy server since it possesses 

1 0 two network interfaces, e.g. , two Ethernet links. 

Normally, this type of network would be extremely difficult to manage, since a 
standard router expects all IP addresses that it serves to fall within a limited range. 
Consistent with the present invention, however, traffic from each of these devices may be 
modified so that the information presented to the network router is acceptable. The 

15 modification may be accomplished by proxy server 20 using a combination of network 
address translation (NAT), a proxy address resolution protocol (ARP) service, and a proxy 
domain name system (DNS) service, as discussed below. NAT is a well-known process 
by which traffic received by and transmitted from a particular device with an arbitrary IP 
address is modified to present the correct IP address to a network router. NAT service may 

20 be specifically configured to translate particular IP addresses. A proxy mobility server 
consistent with the present invention may translate random IP addresses dynamically. 

Figure 2 illustrates a high level diagram of proxy server 20. As shown, proxy 
server 20 includes a processor in communication with a hard drive, a system memory, and 
a user memory. The system and user memories may include read-only and/or random 

25 access types of memories. These memories are useful for storing packet contents, which 
may includes addresses and the like, as well as data content and packet length, to name a 
few. Proxy server 20 also includes interfaces, which may take the form of cards, through 
which proxy server communicates with networks. In the example shown, proxy server 20 
is interfaced with a legal/public network and a random network through Ethernet interface 

30 0 and Ethernet interface 1 , respectively. 

Figures 3 and 4 depict the routing of information, such as an IP packet 26, from a 
device within a random LAN 28 to a device within a "legal" LAN 30. For purposes of this 
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discussion, a "legal" LAN is simply a public LAN, t e. , one with a legal set of IP addresses. 
In Figure 3, packet 26 from the device, which has an IP address of 47.3 1 . 1 28. 1 95, is routed 
from random LAN 28 to proxy server 20. As shown, proxy server 20 is a server for a 
subnet (here denoted 137.1 18. 199.X) which, as is known, is a set of machines that are 

5 physically connected together in an Ethernet LAN, e.g., the legal LAN 30 in Figure 3. 
Proxy server 20 performs a network address translation and, as shown in Figure 4, the 
translated packet 32 is transmitted to the legal LAN. The translation may be performed 
using known techniques, such as those specified in Internet Engineering Task Force 
Request for Comments (IETF RFC) 1631. A packet following the opposite path, i.e., 

10 packet 34 routed from a device within legal LAN 30 to a device within random LAN 28, 
would also undergo network address translation (to translated packet 36) in proxy server 
20 (see Figures 5 and 6). 
Proxy ARP 

In addition to NAT, proxy server 20 may employ a proxy address resolution 
15 protocol (ARP) service to provide mobile functionality consistent with the present 
invention. ARP is a known protocol which may be used by a network device to discover 
what other devices are connected to the local network. Proxy ARP service allows TA 
proxy server 20 to "spoof ' mobile network IP devices having random IP addresses into 
thinking that server 20 is the device with which those mobile IP devices wish to 
20 communicate. This is necessary when the mobile IP device first boots and attempts to 
determine its gateway. As is known, existing proxy ARP implementations are limited in 
their use since only traffic from certain select specific addresses can be handled. Proxy 
ARP consistent with the present invention is not so limited and may be used to identify any 
arbitrary address. 

25 Figure 7 illustrates an ARP packet 38 being transmitted by a mobile device in 

random LAN 28 to proxy server 20. As shown, ARP packet 38 includes the address of the 
sending device, as well as a query from the device regarding the whereabouts of its 
gateway, which has the address of the gateway sought. The gateway, which may be a 
network router, connects the smaller LAN {e.g.., a random LAN) to a larger WAN (e.g., 

30 a public LAN, such as the "legal" LAN 30 of Figure 7) and passes traffic from the LAN 
to the WAN. When a mobile device in the random LAN wishes to send traffic to a device 
having an arbitrary address in a second network (e.g., the WAN) outside of the LAN, the 
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sending device needs to know to which gateway device the traffic should be sent. While 
normally the gateway is on the same network as the mobile device that is searching for it 
(using the ARP), this is not possible in a random LAN. Accordingly, the proxy server 
pretends that it is the gateway, and the mobile device will use it to reach the WAN. In 
5 response to receiving ARP packet 38, proxy server 20 generates an ARP response packet 
40 destined for the sending device in random LAN 28. As shown in Figure 8, response 
packet 40 includes the sending device's IP source address as the destination address and 
informs the sending device that proxy server 20 is the device's gateway. 

Figure 9 depicts steps for proxy ARP consistent with the present invention. During 

10 initialization (step 80), IP addresses and network masks are determined, as shown in 
greater detail in Figure 10. First, a raw socket is created to examine ARP packets (step 
100). This socket is .a communications programming interface created between proxy 
server 20 and the random and public LANs. In the Redhat Linux operating system, only 
one such socket is needed, whereas other operating systems, such as Sun Microsystem's 

1 5 Solaris operating system, must create one socket per Ethernet interface. Next, IP network 
masks for both the public LAN interface and the random LAN interface are identified 
(steps 102, 104). As is known, these interfaces may be cards in proxy server 20. This 
information, used by the proxy server in combination with other information to determine 
what set of devices are part of the networks and, therefore, whether it can send packets 

20 directly to any mobile device or whether the packets must be sent through a router, is 
typically maintained in a stable storage device, such as hard disk, flash memory, and the 
like, in proxy server 20. Similarly, IP addresses of the public and random LAN interfaces 
are identified (steps 106, 108), as is the medium access control (MAC) address of the 
random interface (step 1 10). Like the IP network masks, these addresses are typically 

25 stored or built into proxy server 20. 

With continuing reference to Figure 9, when a new ARP packet from a random IP 
device, such as ARP packet 38 of Figure 7, arrives at the random network interface from 
a mobile IP device in the random LAN (step 82), proxy server 20 retrieves the packet 
contents from the operating system (step 84). The packet, as is known, has a header and 

30 data, which includes inter alia the packet source address {i.e., the address of the mobile 
device that sent the ARP packet) and the packet destination address (/'. e. , the address of that 
device's gateway). The server then applies the ARP data format to the IP packet (step 86). 
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The ARP data format is defined in IETF Standard 37, and the application of the format to 
the data may be done using the standard method of casting. 

Next, the proxy server performs a proxy ARP network determination to determine 
the network to which the IP packet is destined for (step 88). Figure 1 1 shows a flowchart 
5 detailing steps for this determination consistent with the present invention. A public 
network ID (PubNetID) is determined first (step 120). In one embodiment, the public 
network ID is derived from the public IP interface address and the IP network mask of the 
public LAN, e.g. , logically "anding" the address with the mask. The proxy server uses the 
PubNetID to discover what network it is part of, i.e. , what IP devices are local and which 

1 0 are not local. Devices that not local are reached through a router. Next, the proxy server 
determines if the IP destination address of the incoming packet is for a "local" network, 
i.e., the public LAN. In one embodiment, a network ID associated with the incoming 
packet (NewNetID) is determined (step 122) based on the destination IP address sub- 
component of the ARP data structure associated with the ARP packet and the IP network 

1 5 mask of the public LAN interface, e.g. , logically "anding" the destination address with the 
public IP network mask. If PubNetID is equal to NewNetID (step 124), the incoming 
packet is destined for a device that has an IP address on the public LAN but is physically 
part of or on the random LAN. The proxy server discards this incoming packet (step 126) 
because another device in the random LAN will receive the packet by Ethernet. The proxy 

20 server simply ignores the packet because it does not need to create a response packet; the 
intended device physically on the random LAN should respond. 

If the incoming packet is not destined for the public LAN, a random network ID 
(RandNetID) may be determined based on the random IP address and the IP network mask 
of the random LAN, e.g., logically "anding" the address with the mask (step 128). The 

25 proxy server uses RandNetID to discover what devices are local to the random LAN. 
Devices that not local are reached through a router. A network ID associated with the 
packet (NewNetID2) is also determined (step 130). This may be determined based on the 
destination IP address sub-component of the ARP data structure associated with the ARP 
packet and the IP network mask of the random LAN interface, e.g., logically "anding" the 

30 destination address with the random IP network mask. The proxy server uses this 
information to determine if the IP destination address of the ARP packet is for a "local" 
network, i.e., the random LAN. RandNetID may then be compared to NewNetID2 (step 
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132). If RandNetld is equal to NewNetID2, the incoming packet is destined for a device 
that has an IP address on the random LAN and physically part of or on the random LAN. 
Again, the proxy server discards the incoming packet (step 134), since another device in 
the random LAN should respond and will receive the packet by Ethernet. 
5 If the incoming packet has not been discarded by the proxy server based on these 

comparisons, the packet is destined for a device outside of a local network, i.e., from a 
device in a random LAN, such as a hotel, to a device outside of that LAN and physically 
part of, for example, a public LAN. Consistent with the present invention, the proxy server 
prepares an ARP response packet (step 136) to the incoming packet to convince the 

1 0 sending device that the proxy server is the device's gateway. The response ARP packet 
format is defined in IETF Standard 37. 

Referring once again to Figure 9, once an ARP response packet has been created, 
a proxy ARP address exchange is performed (step 90), as shown in Figure 12. Consistent 
with the present invention, the IP source address component from the incoming packet is 

15 copied into the destination address component of the response packet (step 140). This 
directs the response packet to the appropriate mobile IP device. Similarly, the source MAC 
address component of the incoming packet is copied to the destination MAC address of the 
response packet (step 1 42). The destination address component of the incoming packet is 
copied into the source address component of the response packet (step 144). Address 

20 exchange consistent with the present invention also contemplates filling in the source 
MAC address component of the response packet with the MAC address of the random 
interface (step 1 46). By inserting the operation component of the response packet with the 
appropriate value in network-byte order (e.g., the value "2" for RedHat Linux 5.0), the 
packet is considered a response packet for purposes of the ARP protocol. 

25 Once the address exchange is completed, the response packet may be written to the 

random Ethernet interface using a standard system call (Figure 9, step 92). When the 
mobile IP device receives the response packet, it will believe proxy server 20 is its gateway 
from the random LAN to outside public LANs. Subsequent traffic destined for public 
LANs will be routed there by the proxy server. 

30 Proxy DNS 

Normally, a mobile network device communicates with a nearby network element 
commonly referred to as a DNS server. The DNS server functions to translate an IP name 
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input by a user, such as "undefined.etherloop.com," into a corresponding IP address, such 
as 137.1 1 8.199.33. Thus, when a mobile IP device user inputs an IP name as an intended 
destination, the device communicates with the DNS server, which then performs a 
translation, e.g., a name lookup. However, with a random LAN, this is not possible. 
5 Figure 13 shows the transmission of a DNS packet 42 from a mobile IP device 

within random LAN 28 to proxy server 20. Consistent with the present invention, the 
proxy server pretends that it is the correct DNS server and handles the DNS translation 
activities. In general, DNS packet 42 includes the IP address of the sending mobile IP 
device, a destination address, i.e., the address of the DNS server, which is typically 

1 0 preconfigured in the device, and the IP name the device is seeking an IP address for. Proxy 
server 20 redirects the request to a local process, i.e., a process within the proxy server 
which, in turn, performs the required translation. After the translation is performed, proxy 
server 20 generates a DNS response packet 44 (see Figure 1 4) which includes the address 
of the sending network device as a destination address and the IP address corresponding 

15 to the IP name. 

Figure 1 5 depicts steps for proxy DNS consistent with the present invention. First, 
the proxy DNS server is initialized (step 150). As shown in Figure 16, during 
initialization, proxy server 20 creates an unreliable datagram protocol (UDP) datagram 
socket (step 170) using known methods. This socket is a communications interface 

20 between the local process (proxy DNS) and the operating system. Proxy server 20 also 
establishes a firewall rule such that any packet headed for any destination in any LAN or 
WAN (i.e., any IP address) from any source in any LAN or WAN with a destination port 
of "53" is delivered to the proxy server 20 at the same port, i.e., port "53" of the server 
(step 1 72). Port "53" is the port for the DNS server of the host machine (a machine with 

25 an IP address). The socket can then be bound to port "53" using standard methods (step 
1 74), such that any DNS query with a destination of port "53" is routed to the local process 
(proxy DNS). The identity of a remote name server physically located outside the random 
LAN on the Internet is also identified by the proxy server using, for example, a 
configuration file or some other known method (step 176). After creating a UDP socket 

30 association between the proxy DNS server and the identified remote name server (step 
1 78), proxy server 20 enters a loop waiting for new connections, such as new DNS queries 
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from the random LAN or DNS responses from the remote name server, using standard 
methods (step 180). 

After proxy DNS initialization, a "random" client (/. e. , a device in the random LAN 
having an IP address, such as 1.1.1.1) makes a DNS query to the identified remote name 
5 server (e.g., having an IP address, such as 2.2.2.2) at port "53" (step 152) using standard 
DNS protocol, e.g., IETF standard 13. Proxy server 20 receives the packet and, based on 
the port address used as the destination port (i.e., port "53"), redirects the packet to the 
proxy DNS server (the local process within the proxy server) (step 1 54) using, for example, 
firewall redirection code built into Linux Redhat 5.0. The proxy DNS server in turn 

1 0 receives the packet and determines the original destination address (/. e. , 2.2.2.2) and port 
(i.e., port "53") of the intended destination, storing them in appropriate variables. In 
Redhat Linux 5.0, this may be accomplished using an appropriate system call to collect the 
packet data from the kernel. 

The proxy DNS server may then send the DNS query packet to the remote name 

1 5 server identified during initialization (step 158). The proxy DNS server creates a new UDP 
socket, a communications interface between it and the remote name server. Typically, the 
proxy DNS server uses a separate socket and port (such as port "2001," in this example) 
which may be arbitrarily assigned) for each mobile device IP address so as to be able to 
identify to which device in the random LAN the response should be sent. The remote 

20 name server then processes and responds to the DNS query from the proxy DNS server, 
as defined in IETF Standard 13 (step 160). A DNS response packet, which includes the 
requested address, is generated by the remote name server and sent to the proxy server 
using the port defined in step 158 (i.e., port "2001" in this example). Proxy server (such 
as proxy server 20) receives the DNS response from the remote name server on the 

25 specified port (i.e., port "2001") using, for example, standard Unix system calls and 
determines the IP address of the client (i.e., 1.1.1.1 in this example) using that port (step 
164). The DNS response is then sent to the client by the proxy server (step 166; see also 
Figure 14), which performs a source address and port modification. In one embodiment, 
the proxy server modifies the source address (the address of the proxy server, e.g., 3.3.3.3. 

30 in this example) and source port of the response packet (the port of the link back to the 
client, which may be arbitrarily assigned) to the original destination address (i.e., 2.2.2.2. 
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in this example) and the original destination port (i.e., port "53" in this example) of the 
DNS query packet, respectively. 
One-Armed Proxy Server 

The TA proxy server described above is extremely well-suited for operation in any 
environment where a fully random assortment of users may attempt to connect to the LAN. 
As previously noted, one such environment is a hotel environment. Today, hotel guests 
frequently have mobile network devices, such as laptops, and wish to connect via Ethernet, 
EtherLoop, or the like, into the hotel's network and from there to the Internet to retrieve 
electronic mail and conduct other business. 

A TA proxy server, however, may not fit well into a LAN networking community 
since most end-user network devices will have a stable IP address, correctly configured and 
assigned for the LAN, unlike the hotel environment. Moreover, a TA proxy server 
increases latency (delay) on a network. For at least these reasons, there is a need for proxy 
routers that do not interfere with the normal operation of a LAN. These services will exist 
on a normally configured LAN and only begin operation only when a random interloper, 
i.e., an individual device, connects to the network. The device that supports this service 
will be lower in cost and will not create any performance problems for the standard 
network traffic. 

Fi gure 1 7 illustrates an alternative proxy server implementation consistent with the 
present invention that satisfies this need. In this implementation, LAN 200 includes a 
plurality of mobile IP network devices 202, 204, and 206 which communicate with a router 
2 1 0 through hub 2 1 2. The links used to interconnect the various network elements shown 
may, for example, be Ethernet links. Proxy server 214 communicates with the various 
network elements through a single link, e.g., a single Ethernet interface. As such, proxy 
server 214 may be referred to as one-armed proxy server. Generally, proxy server 214 
includes the same hardware as proxy server 20 (Figure 2). The same Ethernet interface 
receives data from LAN 200 and delivers translated data back to the LAN. In Figure 17, 
the majority of the devices on the network are on the same network as the router. These 
devices operate normally without any interference from proxy, server 214, which is always 
listening to the traffic on this network. Device 208, an interloper with an address of 
47.3 1 ,128. 195 will not be able to directly communicate with the router, which ignores all 
traffic from an address that is not in its network domain (i.e., 137.1 18. 199.X). One of the 
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benefits of this implementation is that the standard network traffic is not interrupted by the 
proxy server, as shown in Figure 1 8. As with the TA proxy server of Figure 1 , one-armed 
proxy server 214 performs network address translation, proxy ARP, and proxy DNS 
services to provide similar fully transparent client functionality to any IP-enable network 
5 device. 

Network Address Translation 

Figure 19 depicts a network environment useful for discussing NAT performed by 
one-armed proxy server 64. Network 220, an Ethernet type of network, includes a 
plurality of interconnected network elements including router 222, workstation 224, hub 

10 226, and proxy server 214. Interloper 228 is also connected to LAN 220, although it is a 
foreign IP-enabled network device relative to the network, i.e., it is not part of LAN 220. 

As shown in Figure 19, interloper 228 generates a packet 230 for a LAN/WAN 
other than the LAN 220. Packet 230 includes the IP address of the transmitting device, 
interloper 228, as well as an IP address of the destination device, which is not particularly 

1 5 shown. Due to the nature of Ethernet networks, every element on the LAN receives packet 
230 from hub 226. The IP protocols within workstation 224 and similar network elements 
recognize that the destination is not a local network device and consequently ignore the 
packet. Router 222 may or may not accept packet 230 depending on the source IP address. 
Even if the router accepts the packet and passes it on to the LAN/WAN, the packet will not 

20 return to the router (address 137.1 18.199.1) since the source address is 47.31.128.195. 

Proxy server 214, however, recognizes that it is capable of properly translating 
packet 230 into translated packet 232 having an acceptable format utilizing known address 
translation methods (see Figure 20), Since translated packet 232 has an associated IP 
address recognizable by router 222, the router believes packet 232 originated from within 

25 LAN 220 and not by a foreign mobile device, i.e., interloper 228. As shown, packet 232 
includes the same destination address as packet 230. Once router 222 receives this packet, 
it can send the packet on to the Internet as normal. 

After the remote device receives the translated packet, it may generate a response 
packet. If so, the response packet 234 must be translated by proxy server 2 1 4 so that it can 

30 be delivered to interloper 228 (see Figure 21). Router 222 knows that the .55 IP address 
is associated with a device on its network. In this case, the device happens to be proxy 
server 2 1 4, but the router is unaware of the presence of the server nor does it matter to the 



WO 99/38303 PCT/US99/01195 

-14. 

router that the destination is the proxy server and not a "normal" network device such as 
a workstation. Instead, router 222 simply forwards response packet 234 to proxy server 
214, just like it would forward any other packet to other network devices. At about the 
same time the proxy server receives response packet 234, interloper 228 also receives the 
5 response packet from hub 226. However, since the interloper 228 knows that its IP address 
is 47.31.128.195, it throws the response packet away. Consistent with the present 
invention, proxy server 214 receives the response packet, performs a reverse network 
address translation, and sends a translated packet 236 back out on the LAN through hub 
226 (see Figure 22). Packet 236 is broadcast across the entire LAN, but since only one 
1 0 device on the network has IP address 47.3 1 . 128. 195 (interloper 228), only that device will 
not discard the packet. Proxy server is able to specifically target the interloper by using the 
interloper's medium access control (MAC) address as the destination. 
Proxy ARP 

Figures 23 and 24 show a network environment useful for discussing the proxy 
1 5 ARP capabilities of proxy server 214. Interloper 228 may generate an ARP packet 238 in 
order to discover the MAC Address of its gateway device, Le. 9 47.31.128.1. Normally, 
since no device in LAN 220 has the appropriate MAC address, packet 238 would be 
ignored and interloper 228 would be unable to function. Consistent with the present 
invention, proxy server 2 1 4 will however recognize that packet 238 does not belong on the 
20 137.118.199.X network and will automatically generate a response (see Figure 24), 
Response packet 240 includes, as a destination address, the IP address of interloper 228, 
as well as a reply to the gateway query. Once interloper 228 receives packet 240, it 
considers the proxy server 214 to be its gateway device and will use the server for all 
further communications outside of the local LAN. The steps for proxy ARP performed by 
25 TA proxy server 20 discussed above are equally applicable to proxy server 214. 
Proxy DNS 

Proxy server 214 is also capable of performing proxy DNS. If, from the point of 
view of the interloper, the DNS server is usually on the same LAN as the interloper, the 
interloper will generate an ARP request for the DNS server. Consistent with the present 
30 invention, the proxy server 214 will respond to the ARP request with its own address. 
Future DNS queries will be delivered directly to proxy server 214, which can then answer 
them. Similarly, if, from the point of view of the interloper, the DNS server is outside of 
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the local LAN, /. e.,ona WAN, the proxy server will automatically receive the DNS query, 
since it is the interloper's gateway. In this case, proxy serve 214 will see the DNS query 
packets arrive and will be able to response to them locally. The steps for proxy DNS 
performed by TA proxy server 20 discussed above are equally applicable to the proxy DNS 

5 service performed proxy server 214. 

In addition to the features described above, proxy servers consistent with the 
present invention support certain security functions to improve network administration. 
For example, each time an interloper connects to an proxy server-enabled network, the 
proxy server will be able to provide connectivity for that user. To improve the security of 

1 0 the network, the proxy server will deliver a message to a specified network administrator 
e-mail account to the alert the administrator to the presence of this new user. While this 
is not ironclad security, it is a reasonable first step in network security. 

Properly configured, proxy servers consistent with the present invention can 
provide interlopers with a secondary gateway. This has at least two benefits, including 

15 reduced congestion on the standard router and improved control over the interloper's 
internet access. Reduced congestion is a relatively straightforward concept, i.e., by using 
a different router than the standard network traffic, it reduces the possibility of excessive 
demand on router resources, that in turn might affect the performance of the standard 
network users. Further, by specifying a secondary gateway, the network administrator can 

20 funnel interlopers into a less open corporate environment, preventing those users from 
reaching sensitive material within the standard corporate network. This is one of the major 
benefits of the present invention over the straight DHCP model, for two reasons. First, if 
the network is served by a proxy server, a stand-alone DHCP server is not needed. The 
standard network users will not need to use DHCP on a day-to-day basis. Given the first 

25 constraint, everyone who uses DHCP is, by implication, an interloper and can be treated 
with additional security restrictions. 

As for other protocols, one of ordinary skill will appreciate that proxy servers 
consistent with the present invention are only capable of supporting IP-based translation 
services. This is primarily because IP is both a LAN and WAN protocol. Other common 

30 LAN protocols, such as Apple Talk, or IPX are significantly limited in scope, and are not 
capable of the "long range" communications that make the proxy server translation services 
possible. However, it may be possible for "bridges" to be built to allow IPX-based 
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computers to communicate with their "home" networks. However, this must currently be 
resolved on a case-by-case basis. 

It will be appreciated by those skilled in this art that various modifications and 
variations can be made to the IP mobility service strategy consistent with the present 
5 invention described herein without departing from the spirit and scope of the invention. 
Other embodiments of the invention will be apparent to those skilled in this art from 
consideration of the specification and practice of the invention disclosed herein. It is 
intended that the specification and examples be considered exemplary only, with a true 
scope and spirit of the invention being indicated by the following claims. 
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We claim: 

1 . A method, for use with a proxy server, for establishing communications 
between a device in a first network and a destination device having an arbitrary address on 
a second network outside of the first network, the method comprising the steps of; 

5 generating an address resolution protocol packet to identify the arbitrary address 

for the destination device; 

receiving, by the proxy server, the address resolution protocol packet; 
generating an address resolution protocol response packet including the arbitrary 
address of the destination device; and 
1 0 transmitting the address resolution protocol response packet from the proxy server 

to the device in the first network. 

2. The method of claim 1 further comprising the step of: 

determining if the proxy server should respond to the address resolution protocol 

1 5 packet. 

3. The method of claim 2 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a device that 
20 has an address outside of the first network but that is part of the first network; and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address outside of the first network but that is part of the first network. 

4. The method of claim 3 wherein the step of determining if the proxy server 
25 should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a device that 
has an address on the first network and that is part of the first network; and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address on the first network and that is part of the first network. 

30 

5 . The method of claim 4 wherein the; step of generating an address resolution 
protocol response packet includes the substep of: 
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generating a response packet if the address resolution protocol packet is destined 
for a device that is outside of the first network. 

6. The method of claim 5 further comprising the step of: 

5 performing an address exchange to direct the response packet to the appropriate 

device. 

7. The method of claim 6 wherein the step of performing an address exchange 
includes the substeps of: 

10 writing an internet protocol source address component of the address resolution 

protocol packet into a destination address component of the response packet; 

writing a source MAC address component of the address resolution protocol packet 
into a destination MAC address component of the response packet; and 

writing a MAC address associated with the first network into a source MAC 
1 5 address component of the response packet. 

8. A system for establishing communications between a device in a first 
network and a destination device having an arbitrary address on a second network outside 
of the first network, the system comprising: 

20 a proxy server in communication with the first network and the second network, 

the proxy server including: 

memory for receiving an address resolution protocol packet generated by 
the device in the first network; and 

a processor, in communication with the memory, for determining if the 
25 proxy server should respond to the address resolution protocol packet with an address 
resolution protocol response packet, the processor also for generating the response packet 
and transmitting the response packet to the device in the first network. 

9. A method, for use with a proxy server, for establishing communications 
30 between a random device and a destination device having an arbitrary address on a 

network, the method comprising the steps of: 
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generating an address resolution protocol packet to identify the arbitrary address 
for the destination device; 

receiving, by the proxy server, the address resolution protocol packet; 
generating an address resolution protocol response packet including the arbitrary 
5 address of the destination device; and 

transmitting the address resolution protocol response packet from the proxy server 
to the random device. 

10. The method of claim 9 further comprising the step of: 

10 determining if the proxy server should respond to the address resolution protocol 

* packet. 

1 1 . The method of claim 1 0 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

15 determining if the address resolution protocol packet is destined for a device that 

has an address associated with the network but that is physically not part of the network; 
and 

discarding the address resolution protocol packet if it is destined for a device that 
has an address associated with the network but that is physically not part of the network. 

20 

12. The method of claim 1 1 wherein the step of determining if the proxy server 
should respond to the address resolution protocol packet includes the substeps of: 

determining if the address resolution protocol packet is destined for a random 
device that is not part of the network; and 
25 discarding the address resolution protocol packet if it is destined for a random 

device that is not part of the network. 

1 3 . The method of claim 1 2 wherein the step of generating an address resolution 
protocol response packet includes the substep of: 

30 generating a response packet if the address resolution protocol packet is destined 

for a device that is part of the network. 
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14. The method of claim 13 further comprising the step of: 

performing an address exchange to direct the response packet to the appropriate 

device. 

5 15. The method of claim 14 wherein the step of performing an address 

exchange includes the substeps of: 

writing an internet protocol source address component of the address resolution 
protocol packet into a destination address component of the response packet; 

writing a source MAC address component of the address resolution protocol packet 
10 into a destination MAC address component of the response packet; and 

; writing a MAC address associated with the random device into a source MAC 
address component of the response packet. 

16. A system for establishing communications between a random device and 
15 a destination device having an arbitrary address on a network, the system comprising: 

a proxy server in communication with the random device and the destination 
device, the proxy server including: 

memory for receiving an address resolution protocol packet generated by 
the random device; and 
20 a processor, in communication with the memory, for determining if the 

proxy server should respond to the address resolution protocol packet with an address 
resolution protocol response packet, the processor also for generating the response packet, 
and transmitting the response packet to the random device. 

25 17. A method, for use with a proxy server, for communicating with a mobile 

device and remote name server and for obtaining an internet protocol address from the 
remote name server for the mobile device, the method comprising the steps of: 

generating a query packet including a request for an address associated with a 
domain name; 

- 30 receiving the query packet from the mobile device in the proxy server; 

forwarding the query packet to the remote name server; 
generating a response packet including the requested address; 
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transmitting the response packet to the proxy server; and 
transmitting the response packet to the mobile device. 

18. The method of claim 17 wherein the query packet includes a destination 
5 port and wherein the step of forwarding the query packet to the remote name server 

includes the substeps of: 

directing the query packet to a proxy DNS server based on the destination port; 

determining, by the proxy DNS server, the address of the remote name server and 
the destination port; and 
1 0 identifying a port associated with the mobile device. 

19. . The method of claim 18 wherein the step of transmitting the response 
packet to the proxy server includes the substeps of: 

receiving the response packet on the port associated with the mobile device; and 
1 5 determining, by the proxy server, the address of the mobile device based on the port 

associated with the mobile device. 

20. The method of claim 19 wherein the response packet includes a source 
address and a source port, and wherein the step of transmitting the response packet to the 

20 mobile device includes the substeps of: 

modifying the source address of the response packet to the address of the remote 
name server; and 

modifying the source port of the response packet to the destination port. 

25 21. A system for obtaining an internet protocol address from a remote name 

server for a mobile device, the system comprising: 

a proxy server in communication with the mobile device and the remote name 
server, the proxy server including: 

memory for receiving an address query packet generated by the mobile 

30 device; and 
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a processor, in communication with the memory, for forwarding the query 
packet to the remote name server and for transmitting a response packet, generated by the 
remote name server and including the requested address, to the mobile device. 

5 22. A method, for use with a proxy server, for providing communications 

between a random device and a destination device in a network, the method comprising the 
steps of: 

performing a proxy address resolution protocol to initiate communications between 
the random device and the destination device; 
1 0 performing a proxy domain name service to identify a destination address in the 

second network associated with a domain name; and 

performing a network address translation of an arbitrary random address associated 
with traffic from the random device to an appropriate address for routing the traffic to the 
destination device in the network. 

15 

23. A system for providing communications between a random device and a 
device in a network, the system comprising: 
a proxy router including 
memory; and 
20 a processor programmed to 

(a) perform a proxy address resolution protocol to initiate 
communications between the random device and the device in the network; 

(b) perform a proxy domain name service to identify a destination 
address in the network based on a destination name; and 

25 (c) perform a network address translation of an arbitrary random 

address associated with traffic from the random device to an appropriate 
address for routing the traffic to the device in the network. 
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